Remote client access platforms and systems, such the Terminal Service™ provided by the Microsoft Corporation, allow computers to remotely access application programs that are hosted by and resident at an application server. In remote client access systems, client computers typically rely on a server computer to provide computing functionality through application programs resident at the server computer. Examples of application programs include word processing, multimedia, and data management programs.
The application server computer may be referred to as a host computer or terminal server. The client computer may be referred to as a remote terminal, remote client, or a thin client. The client computer primarily is used for user interface: interaction with a user and device I/O. Software on the client computer is typically generic or not application specific, generally consisting of an operating system and general purpose software—including software to support the remote client access environment. Software at the server computer typically includes specific-purpose application software that provides particular functionality, such as database access, word processing, drafting, and many other types of applications. Data communicated between the client computer and the application server mostly includes commands and data relating to user interface, such as graphics data, keystrokes, mouse movements, etc., as well as commands and data relating to hardware devices located at the client computer.
The application server and clients typically communicate or pass information with one another using a predefined communication protocol such as the remote desktop protocol (RDP) as defined by the Microsoft Corporation. Lower level network protocols such as TCP/IP are also involved.
Benefits of remote client access systems are that the client computers can be relatively low-powered since most functionality and computation takes place at the server computer. Although the application server is often more expensive than a typical desktop computer, one application server computer can service many less expensive clients.
Another advantage in some systems is that data can reside at the physical location of the server computer, and can be acted upon at that location by application programs without having to be transferred over relatively slow communications links to the client computers—only the user interface is implemented at the physical locations of the client computers.
Client computers often have USB (universal serial bus) ports to which peripheral devices are attached. Such devices often relate to the user interface, as in the case of USB keyboards. In many cases, applications executing at the server computer need to access and interact with such USB devices. Other examples of USB devices include digital cameras, document scanners, external disk drives, and media readers. Various applications hosted by the application server may need to interact with these hardware devices.
In a typical Windows®-based desktop environment, local applications communicate with USB devices through a series of drivers, referred to as a driver stack. Different responsibilities are divided among components of the stack for purposes of organization and re-usability. For example, some of the drivers are generic to all or certain general classes of USB devices and can be used or re-used to communicate with many different devices. Other drivers implement functionality that is specific to certain devices, and are often designed specifically to accompany certain hardware.
FIG. 1 illustrates a typical USB architecture implemented within a computer acting as a standalone computer—not as a client of an application server. FIG. 1 shows logical communications between hardware and software components.
The system of FIG. 1 includes a computer 100 and a USB device 105. USB device 105 is connected to computer 100 through a physical USB port (not shown). An application program 110 executes on the computer and interacts with USB device 105 through a driver stack 115. The driver stack 115 in this example has three USB drivers.
At the lowest level of the driver stack 115, a USB host controller driver 120 communicates directly to the USB hardware (not shown) in the computer, and through that hardware to the USB device 105. Above that, a low-level USB bus driver 125 (also referred to as a hub or hub driver) communicates with USB host controller 120, and manages USB device power, enumeration, and various USB transactions. Both of these drivers are part of the Windows® operating system and are generic to all USB devices; these drivers do not have to be replaced or modified as a function of the type of USB devices that are connected to the computer 100.
Driver stack 115 also includes a USB function driver 130. The USB function driver 130 is customized for a particular device or class of devices. As a result, a different function driver is loaded depending on the actual USB device being used. USB function drivers are also referred to as USB device function drivers, class drivers, or custom drivers.
Although FIG. 1 shows only a single application program 110, computer 100 typically has a plurality of application programs, any one or more of which may be configured to interact with USB device 105 through the single driver stack 115 shown. Application program 110 may be a word processing program, a game program, or any of various other types of programs.
FIG. 2 shows a similar example in which a computer 200 has a plurality of application programs 205 and 210 and a plurality of USB devices 215, 220, and 225. In this example, application program 205 interacts with USB device 215, while application program 210 interacts with USB devices 220 and 225.
As in the previous example, communications are implemented by a USB driver stack 230. The USB driver stack 230 includes a USB host controller 235 and a USB bus driver 240 that communicate with each of USB devices 215, 220, and 225. The USB driver stack 230 further includes a plurality of USB function drivers 245, 250, and 255 corresponding to each of USB devices 215, 220, and 225. As already described, each of these USB function drivers 245, 250, and 255 is selected and loaded based upon the particular type or class of USB device.
As shown, an application program can interact with more than a single USB device. If multiple USB devices are installed, they commonly use the same host controller driver and bus driver, although it is possible for a single computer to have more than one USB driver stack. If different kinds of USB ports are used, different port and “mini-port” drivers may be loaded; however, in general the overall USB driver stack remains the same.
FIG. 3 illustrates use of USB devices in a prior art remote client/server architecture. In this example, a client computer 300 has one or more USB devices 305(1)-305(N) connected to its USB ports. It also has operating system or other low-level support for such USB devices. In particular, remote client computer 300 includes a USB host controller 310 that connects with USB devices 305.
Client computer 300 performs user interaction in response to commands and data transferred between itself and a server computer 315. One or more application programs 320 reside at server computer 315 and execute thereon. In order to support remotely located USB devices 305, the operating system or other support software of server computer 315 includes USB support. In particular, server computer 315 includes USB function device drivers 325(1)-325(N), a USB bus driver 330, and a USB host controller 335.
USB function device drivers 325 perform similar functions as USB function device driver 130 described above. USB function device drivers 325 communicate with a USB bus driver 330. Likewise, USB bus driver 330 performs similar functions as USB bus driver 125 described above. Server computer 315 further includes a USB host controller 335 connected to or communicating with USB host controller 310 of client computer 300. Communication between USB host controller 310 and USB host controller 335 may be through a direct physical connection or include an intermediate network connecting the two. USB host controller 335 through communication with USB host controller 310 communicates with and accesses USB devices 305. In this example, client computer 300 relies completely on server computer 315 to provide all the needed functionality through application programs 320 for USB devices 305.
In contrast to the operation of the standalone computer shown in FIG. 1, in the client server arrangement of FIG. 3, all functionality in the form of application programs 320 is provided at the server computer 315. In other words, the client computer 300 relies on server computer 315 for all functionality for USB devices 305. In this arrangement, client computer 300 does not provide, or is not allowed to provide, any functionality to any of the USB devices 305.